(19) 



Europatsches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(43) Date of publication: 

05.08.1998 Bulletin 1998/32 

(21) Application number: 98200627.2 

(22) Date of filing: 25.06.1993 



(n) EP 0 856 788 A2 

EUROPEAN PATENT APPLICATION 

(51) intci A G06F 9/45, G06F 9/44 



(84) 


Designated Contracting States: 


(72) Inventor: Brett, Bevin R. 




DE FR GB IT 


Merrimack, NH 03054 (US) 


(30) 


Priority: 26.06.1992 US 905930 


(74) Representative: Roberts, Gwilym Vaughan et al 




26.06.1992 US 904816 


KILBURN & STRODE, 




26.06.1992 US 906212 


20 Red Lion Street 




26.06.1992 US 905929 


London WC1R4PJ (GB) 


(62) 


Document number(s) of the earlier application(s) in 


Remarks: 




accordance with Art. 76 EPC: 


This application was filed on 27 - 02 - 1998 as a 




93915471.2/0 603 375 


divisional application to the application mentioned 






under INID code 62. 


(71) 


Applicant: DIGITAL EQUIPMENT CORPORATION 






Maynard, Massachusetts 01745 (US) 




(54) 


Smart recompilation of source program 




(57) 


A method and system for compiling a source 


mation, which is generated during a code generation 



program 1702 using smart recompilation. The invention 
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Description 

Background of the Invention 



"smart recompilation" procedure 
a. General Discussion 
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The following paragraphs discuss reasons why it is sometimes necessary to recompile many source modules 
when a single source module is changed Fig. 3 shows a plurality of source code programs ("modules') having various 
"dependencies" upon -one another. The source code modules are scored in a memory (not shown). In Fig. 3, a first 
source code module 300 named "ModuleA" includes a declaration of a subroutine "Sub-A" and a declaration of a 

5 subroutine "Sub-B". Subroutine Sub-A- is a "global" subroutine, which means that it may be called by modules other 
than the module in which it is declared. A second source code module 302 named "Mo'duleB" includes a call to the 
global subroutine "Sub-A" that is included in ModuleA. ModuleB also includes a declaration of a global subroutine 
named "Sub-C". A third source code module 304 named "ModuleC calls Sub-C. A fourth source code module 306 
named "ModuleD" calls Sub-B of ModuleA. 

10 Because ModuleB calls a subroutine declared in ModuleA, ModuleB is said to "depend" on ModuleA. Similarly, 

because ModuleC calls a subroutine declared in ModuleB, ModuleC depends on ModuleB and indirectly depends on 
ModuleA. Because ModuleD calls a subroutine declared in ModuleA, ModuleD also depends on ModuleA. 

In some conventional systems, if changes are made to any of the contents of ModuleA, ModuleA must be recom- 
piled. In addition, all modules which depend on ModuleA, i.e., ModuleB, ModuleC, and ModuleD, also must be recom- 

is piled whenever ModuleA is recompiled. In conventional systems, all dependent modules must be recompiled in this 
situation because it is not possible to determine whether a change made to ModuleA is a change that affects a de- 
pendent module. For example, if the declaration of subroutine Sub-A in ModuleA is changed, this change will not affect 
ModuleD. In some conventional systems, however, ModuleD must still be recompiled because it depends on ModuleA. 
The contents of the changed ModuleA can be viewed as a second source program. Compiling the second source 

20 program operates to produce a second translation result, and to replace a first translation" result with the second trans- 
lation result. 

b. Smart Recompilation 

25 Other conventional systems have modified the dependency concept so that not all dependent modules must be 

recompiled when changes are made to a module, such as ModuleA. This type of compilation is called "smart recom- 
pilation". Fig. 4 shows a plurality of source modules similar to the source modules of Fig. 3. The source code modules 
are stored in a memory (not shown). 

In Fig. 4 r each source module is broken into a number of parts called "fragments". Conventional fragmentation will 

30 be discussed below in detail. Each dependent module depends on a fragment, not on an entire module. Thus, for 
example, ModuleB depends on a fragment 310 ol ModuleA because ModuleB contains a call to Sub-A, which is declared 
within fragment 310. ModuleB does not depend on, for example, fragments 309 and 311 of ModuleA because ModuleB 
does not reference any of the contents of fragments 309 and 311. Similarly, because ModuleC calls a subroutine 
declared in fragment 31 3 of ModuleB, ModuleC depends on fragment 31 3 of ModuleB. ModuleD depends on fragment 

35 311 of ModuleA, but does not depend on fragments 309 or 310. 

In conventional smart recompilation systems, if changes are made to any of the contents of a fragment in, for 
example, ModuleA, ModuleA must be recompiled. In addition, all modules which depend on the changed fragment 
also must be recompiled. For example, if the declaration of subroutine Sub-A in ModuleA is changed, ModuleA wilt be 
recompiled,*and ModuleB, which depends on fragment 310, also will be recompiled. Because fragment 313 does not 

40 change, ModuleC does not need to be recompiled. ModuleD, which does not depend on fragment 310, also does not 
need to be recompiled. Thus, in Fig. 4, fewer modules need to be recompiled when a change -is made to Sub-A than 
when a change is made to Sub-A of Fig. 3. 

Fig. 5 shows a flow chart 500 of a method used for smart recompilation in conventional systems. It should be 
understood that the steps of flow chart 500 and of all the flow charts discussed herein can be performed by a processor 

4 5 of a data processing system. The steps o1 flow chart 500 can be performed by, tor example, processor 20 of Fig. 1 
executing compiler 60 of Fig. 1. 

In step 502, processor 20 creates fragments from the source program to be compiled. In conventional smart rec- 
ompilation systems, the fragments are generated directly from global identifiers in the source program, where each 
global identifier is in a separate fragment, and the fragments do not contain any information from the code generation 

50 phase. In conventional smart recompilation systems, fragments contain only simple, semantic information, such as the 
names of global identifiers and their types, that is not dependent on code generation. 

In step 504, processor 20 compares the newly created fragments to fragments created previously to determine 
which fragments reference changed global identifiers, i.e., which dependent source programs need to be recompiled. 
In step 506, processor 20 generates object code for the source module that needs to be recompiled. • 

55 

c. The "Smart Recompilation' Problem 

Each time compiler 60 is executed for a specific module is called an "invocation" of compiler 60. Information gen- 
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first global context table generated from a previous version of the source program, the first global context table being 
divided into a first group of fragments; generating a second global context table from the source program to be rec- 
ompiled, the second global context table being divided into a second group of fragments; sorting at least the second 
groups of fragments: and using a comparison function to search the sorted table to identify fragments that may be 
5 equivalent. 

Described herein is a method of recompiling a source program, the method being performed by a data processing 
system, comprising the steps of: storing a group of fragments organized as a tree structure of a first global context 
table of a previous version of the source program; generating a group of fragments from a second global context table 
of the source program to be recompiled; determining a first level identifier in the first group of fragments; determining 

io a second level identifier in the first group of fragments; determining a first level identifier in the second group of frag- 
ments; determining a second level identifier in the second group of fragments; and matching the second level identifier 
in the first group of fragments to the second level identifier in the second group of fragments by: sorting a combined 
key, merging the resulting two lists, and recognising duplicate entries in the resulting two lists. 

The invention also resides in a method of generating a machine executable program as recited in clauses 12 and 

is 20 below. Further expression of the invention are also set out in the following clauses: 

1. A method of compiling a source program as performed by a data processing system, said method comprising 
the steps of: 

storing a first global context table generated from a previous version of the source program, said first global 
context table being divided into a first group of fragments; 

generating a second global context table from the source program to be recompiled, said second global context 
table being divided into a second group of fragments; 

sorting one of the groups of fragments; and using a comparison function to search the sorted fragments to 
identify corresponding fragments from said first and second groups which may be equivalent. 

2. The method according to clause 2, wherein the storing step includes the substep of assigning each fragment 
in the first global context table a version number; and wherein the comparing step further includes the substep 
of assigning a new version number to the second fragment when the first fragment does not match the second 
fragment. 

3. the method according to clause 1 , further including the step of recompiling a second source program, having 
a dependency on the second fragment, when the second first fragment is different from the second fragment. 

4. The method according to clause 1, wherein the first and second global context tables include semantic 
information, wherein the semantic information comprises at least one of a nature identifier, a type identifier, a 
number of parameters, and a type of parameters. 

5. The method according to clause 1 , wherein the first and second global context table include invocation- 
specific information, wherein the invocation-specific information comprises at least one of a global symbol 
name, size information and representation information for a variable, and offset information for a stack, 

6. The method according to clause 1 , further including a step of compiling a source file to create an object file, 
wherein the object file includes a global symbol table, wherein the global symbol table further includes a pro- 
gram section contribution table. 

7. The method according to clause 4, wherein the comparing step includes the substep of comparing the 
semantic information of Ihe first global context table with the semantic information of the second global context 
table. 

8. The method according to clause 5, wherein the comparing step includes comparing the invocation -specific 
information of the first global context table with the invocation -specific information of the second global context 
table. 

9. The method of clause 1, wherein the comparing step includes the substep of comparing a first fragment 
from the first group of fragments and a second fragment from the second group of fragments in accordance 
with a "less than or equal to" function. 

10. The method of clause 1, wherein the comparing step includes the substep of comparing a first fragment 
from the first group of fragments and a second fragment from the second group of fragments in accordance 
with a "greater than" function. 

11. A method of recompiling a source program, the method being performed by a data processing system, 
comprising the steps of: 

storing a group of fragments organised as a tree structure of a first global context table of a previous 
version of the source program; 

generating a group of fragments from a second global context table of the source program to be recom- 
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piled; 

determining a firsl level identifier in the first group of fragments; 
determining a second level identifier in the first group of fragments- 
determining a first level identifier in the first group of fragments: 
determining a second level identifier in the second group of fragments" and 

matching the second level identifier in the first group of fragments to the second level identifier in the 
second group of fragments by: mine 
sorting a combined key, 
merging the resulting two lists, and 
recognising duplicate entries in the resulting two lists. 

IL^*^ 9enerating a machine executable program, using first and second programs in a computer 
system including a memory, the method comprising the steps of: "Jmpuier 

translating a first program to produce a first translation-result including invocation specific informatiorr 
placrng the first translation result into a memory structure" '".ormauon, 

reTuhir a t a o^n"f T ram WhlCh 15 di " Grent fr ° m the ' iret Pr ° 9ram ' ,0 P roduce a second translation^ 
result in accordance with invocation specific information in the first translation result and 

select.vely replacing the first translation result with the second compilation result in the memory structure. 
1 3. The method of clause 12, whe.ein the step of translating the second program includes the substeps of 
segmenting the second program into a plurality of parts; and 

storing a value into a memory area corresponding to one of the plurality of parts, the value being deter- 
mined by the first translation result. 

to aTcZu™ » h 3USe TT St0nn9 St6p inC ' UdeS the SUbStS P ° f storin 9 a valu ° corresponding 
to an offset from a beginning of a data area in the machine executable program 

15. The method of clause 12. wherein the step of translating the first program includes the substeps of 
segmenting the first program into a first plurality of parts; and 

storing a first value into a memory area corresponding to a first part of the first plurality of parts the first 
^e^Z^ tranS ' a,i0n - — " *• "P - - -cond p" 

segmenting the second program into a second plurality of parts 

associating a first part in the second plurality of parts with the first part in the first plurality of parts and 

. h ™n S H C T I 'T 3 mem0fy area corres P°" din 9 to the first part of the second pluraMy of' parts 
the second value being determined by the first value. 

for me fi,T.ta^and C l U f '\"* M " >n ,he S,orin 9 ste P includes » -"step of storing an alphanumeric name 
tor the first part and wherein the segmenting steps each include the substep 

^nnT,! n9a f! Ph f PartS ' i " ClUdin9 3 Part iden,i, y in 9 a P""a'«y o1 other parts, and wherein the associ- 
ating step includes the substep of 

sorting the plurality of other parts. 
17. The method of clause 12, wherein the step of translating the second program includes the substep of 

*> U^^^^T W ^° naMa ' P '° 9ram ' Whefein StSP °' ,ransla,in 9 ,he third P r °9 ram 

S TT ( machine - e * ecute *le Program containing a reference to a physical memory address 
corresponding to the first machine-executable program, and wherein the method further includes the step 

* p^gram n9the Se °° nd machinB - execu(ab,e P r °9'ams .0 produce a combined machine-executable 

the L h bsIep S h oT " C ' aUSe 17 ' Wherei " S,6P °' UanS,atin9 * hS ,,rS ' mach ine-execu.able program inctudes 
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syntactically analysing a higher level language program; 

generating the second program to have a plurality of sections, each section having a section address 
accessible by a respective section name, and wherein the step of generating the second machine-exe- 
cutable program includes the substep of 

generating the physical memory reference by accessing the section address by using a section name, 
and adding an offset to the section address. 

1 9. A method of generating machine executable instructions comprising the steps of: 

translating a first source file having a first contents to produce a first translation result in accordance with 
the first contents, the first translation result having a plurality of externally visible entries; 
changing the first source file to have a second contents different from the first contents; 
translating the first source file having the second contents to produce a second translation result in ac- 
cordance with the second contents and invocation specific information in the first translation result, the 
second translation result having a plurality of externally visible entries, including the substep of associating 
an entry in the second translation result with an entry in the first translation result; and determining whether 
the first translation result is substantially different from a corresponding part of the second translation 
result. 

20. A method of generating a machine executable program, using a plurality of programs, in a computer system 
including a memory, the method comprising the steps of: 

translating a first program to produce a first translation result; 
placing the first translation result into a memory structure; 

translating a second program, the second program differing from the first program, to produce a second 
translation result in accordance with invocation specific information in the first translation result; 
determining whether the first translation result is substantially different from the second translation result; 
replacing the first translation result with the second translation result in the memory structure; and 
selectively retranslating a third program in response to whether the first translation result is substantially 
different from the second translation result. 

21 . The method of clause 20, wherein the step of translating the second program includes the substep of 

generating a first machine-executable program, and wherein the step of translating the third program 
includes the substep of generating a second machine-executable program containing a reference to a 
physical memory address corresponding to the firsl machine-executable program, and the method further 
includes the step of 

combining the first and second machine-executable programs to produce a combined machine-executable 
program, wherein the steps of translating the first machine-executable program includes the substeps of 
syntactically analysing a higher level language program; 

generating the second program to have a plurality of sections, each section having a section address 
accessible by a respective section name, and wherein the step of generating the second machine-exe- 
cutable program includes the substep of 

generating the physical memory reference by accessing the section address by using a section name, 
and adding an offset to the section address. 

22. A method of generating machine executable instructions comprising the steps of: 

translating a first source file having a first contents to produce a first translation result in accordance with 
the first contents, the first translation result having a plurality of externally visible entries; 
changing the first source file to have a second contents different from the first contents: 
translating the first source file having the second contents to produce a second translation result in ac- 
cordance with the second contents and invocation specific information in the first translation result, the 
second translation result having a plurality of externally visible entries, including the substep of associating 
an entry in the second translation result with an entry in the first translation result; 

determining whether the first translation result is substantially different from a corresponding part of the 
second translation result; and 

selectively retranslating a second source file in response to whether the first translation result is substan- 
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ttally different from the second translation result. 
Brief Description of the Drawings 

accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several 
exemplary embodiments of the invention and, together with the description, serve to explain the principles of the in- 
vention. In the drawings; 

Fig. 1 is a block diagram of a computer system; 
Fig. 2 is a flow diagram of a conventional compilation process; 
Fig. 3 is a block diagram explaining dependency for a conventional system; 
Fig. 4 is a block diagram explaining dependency for a conventional smart recompilation system; 
Fig. 5 is a flow chart showing a conventional smart recompilation method; 
Fig. 6 is a block diagram of a preferred embodiment of the present invention; 
Fig. 7 is a flow chart of a preferred embodiment of the present invention; 
Fig. 8(a) is an exemplary source program written in the Ada programming language; 
Fig. 8(b) is an example of fragmentation of the source program of Fig. 8(a); 
Fig. 9 is a diagram of an object file format; 

Fig. 10 is a diagram of a Global Context Table in a compilation library of Fig. 6; 

Fig. 11 is a flowchart showing further details of the flow chart of Fig. 7 for storing a first Global Context Tablet 
Fig. 12 is a flowchart showing further details of the flow chart of Fig. 7 for creating semantic information in 'the 
Global Context Table; 

Fig 1 3 is a flowchart showing further details of the flow chart of Fig. 7 for creating invocation specific information 
in the Global Context Table; 

Fig. 14(a) is an exemplary source program written in the Ada programming language; 
Fig. 1 4(b) an exemplary source program written in the Ada programming language- 
Fig. 15(a) is an example of a Global Context Table generated from the source program of Fiq 14(a) 
Ftg. 15(b) is a continuation of Fig. 15(a); 

Fig. 16 is an example of a fragment table for a fragmented Global Context Table of Figs 1 5(a) and 15(b)- 
Fig. 1 7 is a data flow diagram of the compiler of a preferred embodiment of the present invention 
Fig. 18 is a flow chart showing a processing of a preferred embodiment of the present invention ' 
Fig. 19 is a flow chart illustrating a step of Fig. 18; " ' 

- Fig. 20 is a flow chart illustrating a step of Fig. 1 9: 
Fig. 21 is a flow chart illustrating a step of Fig. 20; 
Fig. 22 is a flow chart illustrating a step of Fig. 18; 
Fig. 23 is a data flow diagram showing a result of processing of a preferred embodiments of the present invention- 
Fig. 24 is a data flow diagram showing a result of processing without the present invention; and 
Fig. 25 is a flow chart of a processing of a preferred embodiment of the present invention. ' 

40 Detailed D escription of Preferred Embodiments 

Reference will now be made in detail to preferred embodiments of the invention, examples of which are illustrated 
. |n the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawinqs 
to refer to the same or like parts. y 

A preferred embodiment of the invention performs fragmentation after code generation and, thus fragments of a 
pre erred embodiment of the invention can include information from the code generation. The present fragments of a 
preferred embodiment are stored in a Global Context Table that is written during cod generation 

A preferred embodiment of the present invention is implemented as a modification to an pre-existing Ada compiler 
..e Digital VAX 0, Ada Compiler V3.0, Digital RISC Ultrix Ada Compiler, and Digital ALPHA OpenVMS Ada Compiler' 
each of which is manufactured by Digital Equipment Corporation. It should be understood that the present invention 
could be implemented by modifying other pre-existing compilers for Ada or for other computer languages The present 
invention could also be implemented, for example, by a compiler that is not based on a pre-existing compiler in ac- 
cordance with the following discussion. At least "Digital," "VAX, " "VMS," "Ultrix," "RISC Ultrix,' and "Open VMS" are 
trademarks of Digital Equipment Corporation. 

Specifically, ihe described embodiment modifies a pre-existing optimizing Ada compiler that does not perform 
smart recompilation so that the compiler does perform smart recompilation. Thus, an optimizing code generation portion 
of the existing compiler is not modified, but modifications are made so that fragmentation is performed on the Global 
Context Table as described below. Hint generation is used to ensure that fragments generated by successive compiler 
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invocations are equivalent whenever possible. 

Fig 6 is a block diagram of a preferred embodiment of the present invention for performing smart recompilation 

on source programs written in languages such as Ada. Certain elements of Fig. 6 correspond to elements of Fig. 2. 

All elements ot Fig. 2 preferably are stored in a memory of a data processing system. Compiler 660 and linker 70 are 
5 executed by a processor of the data processing system. Fig. 6 shows a compilation library 680, which includes various 

tables as discussed below. Hint reader 65 is discussed in detail in connection with Fig. 1 7 below. 

Compilation library 680 includes a Dependency Table 600. Dependency Table 600 includes an entry for fragments, 

such as fragments 610 and 812 in a Global Context Table 606. As shown in Fig. 6, a first entry of Dependency Table 

600 lists all modules that on fragment 810. e.g., ModuleM. A second entry of Dependency Table 600 lists all modules 
10 that depend on fragment 812, e.g., ModuleN. Other dependencies of these and other fragments exist in Dependency 

Table 600 but are not shown for purposes of clarity. 

Each entry of Dependency Table 600 also includes a version identifier ("version id"). Each time a fragment is 

changed so that it is no longer equivalent to the previous, pre-change, fragment, the fragment is assigned a different 

version id as discussed below. Dependency Table 600. contains the version id of a fragment on which the dependent 
J5 module'last depended. In Fig. 6, for example, both entries in Dependency Table 100 contain aversion id of "1 indicating 

that the dependent modules were last compiled for version "1 " of the respective fragments from which they depend. 

In a preferred embodiment, dependency table may have other formats than the format shown. 

Compiiation Library 680 also includes a Global Context Table 606. Global Context Table 606 contains definitions 

of all subroutines, variables, constants, etc, that are globally defined, i.e., that can be relerenced by modules outside 
20 of the modules in which they are defined. Global Context Table 606 is written during compilation of object code. Global 

Context Table 606 is broken into fragments, as described below. Global Context Table 606 preferably contains both 

semantic information and invocation specific information. Examples of entries in Global Context Table 606 are shown 

in Fig. 15. 

Compilation library 680 includes a Fragment Table 602. Each entry in Fragment Table 602 corresponds to a trag- 
us ment of Global Context Table 606. Fragment Table 602 is generated by fragmenting Global Context Table 606 after 
generation of object code. Fragment Table 602 has pointers 608 into the Global Context Table 606, as described further 
in connection with Figs. 15 and 16. 

Most fragments directly correspond to a global identifier such as a type definition, constant definition, or functional 
procedure definition Some fragments, however, correspond to other structures. For example, a fragment is created 
30 to represent all the declarations of an overloaded procedure. 

For the purposes of example, a first entry of Fragment Table 602 includes a global identifier "PKG", which is the 
name of an entity defined in fragment 810 of Fig. 8. The entry points to an entry in the Global Context Table containing 
semantic and invocation specific information for PKG (pointer 608). A second entry of Fragment Table 602 includes a 
name I, which is the name ot an entity defined in fragment 812 of Fig. 8. The entry points to an entry in the Global 
35 Context Table containing semantic and invocation specific information for I (pointer not shown). Names of various types 
ol identifiers can appear in Fragment Table 602. Other examples of entries in Fragment Table 602 are shown in Fig. 
16. Other entries in Fragment Table 602 point to fragments for global identifiers in other modules. The fragments for 
each module preferably are organized in the Global Context Table as a tree structure, as shown in Fig. 8(b). 

Each entry of Fragment Table 602 also includes a version id for the fragment. Whenever a module is changed and 
40 recompiled, each fragment that is altered by the change is given a new version id, as discussed below in connection 
with Fig. 7. Each version id in the Fragment Table preferably is unique to the current invocation of the compiler in which 
the source module corresponding to the fragment was compiled. In a preferred embodiment, the version id is a word 
at least 64 bits long. The contents of the version id preferably is determined by a compilation starting time for source 
program 202 and by one or more other factors, such as a name of compilation library 680. 
4 $ Fig. 6 shows a fragmentation system in accordance with a preferred embodiment of the present invention. After 

a ModuleQ (not shown) defining both "PKG" and "I" is changed and recompiled, if fragment 812 changes, a new version 
id, i.e., "2", is stored in the second entry of Fragment Table 602. If fragment 810 does not change, a new version id is 
not entered in the first entry of Table 602. In Fig. 6, Dependency Table 600 shows that ModuleN depends on fragment 
812, and therefore ModuleN will also be recompiled and a version id of "2" will be stored in the second entry of De- 
so pendency Table 600. ModuleM, which depends on unchanged fragment 810 does not need to be recompiled and the 
version id in the first entry of Dependency Table 600 will not change. 

Compilation Library 680 also includes a plurality of object files. These object files will be described in detail below 
in connection with Fig. 9. In this example, the object files include object programs 212, 216, and 218 that are input by 
linker 70. The object files in compilation library 680 also include other object files (not shown) generated from other 
55 source programs (not shown). 

In general, compiler 660 places data areas for the variables in a section of memory separate from program sections 
containing instructions as described below in connection with Fig. 9. Compiler 660 may place all procedures of a source 
program into a common section, or may place the procedures in separate sections. 
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omp anon caused that fragment to change, and a new version id is assigned to the second fragment in steo 710 ThP 
function used lo determine whether two fragments match is described m Figs 19 and 20 P 

Con Sbte 606^ TZJZT" " SW ' ra9menl and its assi 9" ad version id in Fragment Table 602 and Global 

cJ^lJ^ZtT TTT- °' ,he P' esent inven,i °". ^compilation is achieved by dividing a Global 

Context Table mto fragments after object code generation, i.e. . after recompila.ion. Whenever a fragment is channel 
modules dependent on the changed fragment are also recompiled and refragmented 9 ' 

of ,h»' 9 iL 8<b) Sh ° W a " eXamP ' e 0< a " Ma aouKB P ro 9 ram and an e >«^P'e of now the Global Context Table 

tZ^Tl^r H r e H n int ° ,,a9mentS Fi9 - 8(31 Sh ° WS 3n 6Xample °< an Ada source ^ogrTm 80^ 
;,h P rl^ 6Clared " S ° U ' Ce pr ° 9ram 800 The S lobal iden,ifi ers include a package name PKG All 

* *"* ,S afe Wl,hin ,h ° " sc °P e ' °< P^kage PKG. Other identifiers include a first integer ,• a type R which is^ 

7La~Zll*T\V and , a ffoalin9 P ° im nUmber C2; ^ 3 PaCka °« -er, whch includes aTecontalb, 3 
I . It is assumed that all identifiers of source program 800 are global identifiers 

r „„2 ? (b > Sh ° W ^ an exam P' e °' how a P^'erred embodimenl of the present invention preferably divides the Global 
F°oZ IJf^N 9memS N0 ' a " in,0mna,i0n " the GIObal Con,ext Table is sh °™ in Fig. B<°). Th ^ fragment ,n 

ernb=d,men.s may fmd it convenient or advantageous to include the record component dec.a^s or cfandcTn 
the same fragment as the record declaration itself. 8 0r 01 an ° C2 

n,„K F ! 9 H 9 IV bl0Ck dia9 ' am °' 3 '° rma ' °' Flles 2l2 ' 2lB . and 2 '8 of Fig. 6. As shown in Fiq 9 an entrv in a 

c oba lT rm r? 8 " ame °' ,hS kSenme ' (9 '° bal Symbo1 name > and a '«**>" in the objea code X- he 
o o™ s^ ' 5 h i P r09fam SeC,i ° n name Pr ° 9fam Sec " 0n oHse ')- Eacb P r °^ a - incfudes^ramy 
a a3a?n offslnn T T '** '°' P '° 9mm SeC,i0n ' Thus ' ,or exam P le ' a 9l°ba. is defined 

°C°T s lTen b ™: Pr ° 9ram SeCti ° n °' a " ° bieCt Pr09ram ' EXamP ' eS °' GIOba ' CO " ,eXt TaWe 606 and ° ,h - 

.ibra~ 9 68 1 0°hav^ IT^ L'^TV" 8 9 ' obal con,ext lable °' a compilation unit ("source module") 1 000 in compilation 
Z^llr 9 a Plu ; all,y ° f declara,,ons ' deluding a «•»! declaration 1001 and second declaration 1002 

.Ik S£Sf £ t ° Sh ° WS inVOCaU ° n Sp6CiflC in, °' ma,i0n 1006 ' * s '° red "K* ^laration Gene, 
^invocation specie m.ormation is information which is specific toa particular invocation of the compiler for a source 

Each declaration is further divided into semantic information 1004 and invocation specific information 100B The 
compilation unit 1000 is stored in the compilation library 680 shown in Fig. 6. information 1006. The 
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Exemplary semantic information 1004 -for a first declaration shown in Fig. 10 includes a nature 1003, an identifier 
1010, and other nature specific information 1012, such as the number of parameters and the type of parameters. 

Exemplary invocation specific information 1006 for the first declaration includes a global symbol name 1018, a 
size 1 020 and representation 1 022 of a variable, and the offset 1 024 within the stack frame of a stack-allocated variable. 
s Fig. 11 is a flowchart showing further details of step 702 of the flow chart of Fig. 7 for storing a first Global Context 

Table. In step 1102, processor 20 creates a Global Context Table (including invocation specific information from the 
code generation) and generates object code. In step 1104, processor 20 divides the first global context table into a 
first group of fragments. The generated object code and fragmented global context table are stored in compilation 
library 680. 

to Fig. 12 is a flowchart showing further details of the flow chart of Fig. 7 for creating semantic information in the 

Global Context Table. The steps of Figs. 12 and 13 have been simplified somewhat for purposes of example. Steps 
1202, 1206, 1210 and 1214 check the declaration for the presence of various items of semantic information. Step 1202 
is a check to determine whether the declaration contains a nature identifier. Similarly, steps 1206, 1210 and 121 4 check 
the declaration in the source module for a type identifier, for other identifiers, and for parameter data, respectively. 

is Steps 1204, 1208, 1212, 1216 and 1218 are used for storing the various items of information in the Global Context 
Table when they are detected by the checking steps just described. When a nature identifier is detected in step 1202, 
it is stored in step 1204. In the same manner when a type identifier is detected in step 1206, it is stored in step 1208. 
When other identifiers are detected in step 1210, they are stored in step 1212. Finally, when parameter data is detected 
in step 1214, steps 1216 and 1218 store the number of parameters and the type of parameters, respectively. 

20 The storage area for each of steps 1204, 1208, 1212, 1216 and 1218 is a semantic information entry in Global 

Context Table 606, as shown in Fig. 6. 

Fig. 13 is a flowchart showing further details of the flowchart of Fig. 7 for creating invocation specific information 
in Global Context Table 606. Steps 1 302, 1 306, 1310 and 1 314 are used to check the declaration for the presence of 
various items of invocation specific information. Step 1 302 is a check to determine whether the declaration contains a 

25 global symbol name Similarly, steps 1306, 1310 and 1314 check the declaration for the size information of a variable, 
for the representation information of a variable, and for the offset information for a stack, respectively. 

Steps 1304, 1308, 1312 and 1316 store the various items of invocation specific information in the Global Context 
Table. When a global symbol name is detected in step 1302, it is stored in the Global Context Table by step 1304. In 
the same manner, when size information for a variable is detected in step 1306, it is stored by step 1308. When rep- 

30 resentation information for a variable is detected in step 1 31 0, it is stored by step 1 31 2. Finally, when offset information 
for a stack is detected in step 1 314, it is stored by step 1 316. 

The storage area used to store information in steps 1304, 1308, 1312 and 1316 is a invocation specific entry in a 
global context table. 

Fig. 14(a) shows an exemplary source program 1402 written in the Ada programming language. As discussed 
35 above, source program 1402 includes an example of "overloaded' variable R which is used as the name of two pro- 
cedures having different types of parameters. Figs. 15 and 16 below are examples, respectively, of the Global Context 
Table 606 and the Fragment Table 602 that are generated by processor 20 executing compiler 660 for source program 
1402. 

Figs. 15(a) and 15(b) are examples of a Global Context Table generated from the source program of Fig. 14(a). 
40 Fig. 16 is an example of a fragment table for indicating the fragments of Global Context Table of Figs. 15(a) and 15 
(b). The tree structures of Figs. 15 and 16 are shown by the indentation of the text in Fig. 15 and by a number of dots 
in Fig. 16. 

Global Context Table 1500 of Figs. 15(a) and 15(b) contains both semantic and invocation specific information, 
which can be intermixed throughout Global Context Table 1 500. Integer value 1 506, procedural specification declaration 
4 5 1504, argument number 1508, and general attributes 1510 are examples of semantic information in Global Context 
Table 1500. Examples of invocation specific information in Global Context Table 1500 include an object variable defi- 
nition 1512, a general attributes definition 1514 for the object variable definition 1512, and a pass mechanism 1516. 

Fig. 16, indicating the fragments of the Global Context Table of Figs. 15(a) and 15(b), shows fragment pointers 
1602 as they are stored in Fragment Table 602 in compilation library 680. Fig. 16 shows 23 fragment pointers 1602. 
so Each fragment pointer 1602 refers to an entry of Global Context Table 602. For example, pointer 1610, which has a 
value of "8 .. 10", indicates that the fragment table entry containing the pointer 1610 corresponds to entries 1504, which 
are entries number 8-10 of Global Context Table 1500 of Fig. 15. Thus, when Global Context Table 1500 was frag- 
mented, entries 8 through 10 were placed in a single fragment. 

Each of the fragment pointers 1602 has a 16-digit hexadecimal version id 1604. In Fig. 16, all of the fragment 
55 pointers 1602 have the same version id: E311E2C3 0095C46C. 

Each of the fragment pointers 1602 has a description 1606. For example, the description 1606 for a first fragment 
pointer 1 602 is "compilation unit Example at line 1 ", and the description 1 606 for a last fragment pointer 1 602 is "constant 
$CODE at line 0". 
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The descriptions 1 S06 correspond to fragments 1 502, as indicated in Figs. 1 S(a) and 1 5(b) which show a details 

gZ,°^ r ba 1 ' T Co h : ,ex , , c Tab,e f 2 Genera,,y ' a ,ra9ment ™> be denned ~ °- « — ofmeS^rs 

Global Context Tab.e of F,gs. 1 5(a) and 1 5(b). including a subroutine, an object variable definition, a constant defW. on 

co™nH P TT am ° nQ ° ,her th ' n9S Fra9menl 15026 of R 9 15 ' a »' ,or » 3" <*** variable de n ion 

Z lr^R7 9 H a r ent P °' nter 1 6066 in R9 ' 6 " Fra9ment 1 5027 ,s a constanl de,initi ° n corresponding to Gagmen, 
pointer 1S067, and fragment 15021 is a subroutine "in- corresponding to fragment pointer 16021 °" a 9 men ' 

ma .i^h! 9 ^ 9raphS deSCfibe 8 me ' h0d °' ' he PreSSnl inven,ion ,or ensurin ° that invocation specific infor- 
mation changes as little as possible for different invocations of the compiler 

Source oL'nram ™ ^ "° W °' C ° mpi ' er 660 °' ^ 6 °' 3 pre,erred ^"odiment of the present invention 

D^r™ 720 and ! I P '°Z * ^ 1 71 °" WhiCh 9enerates an internal form of source 

KTc ontex. tab.' P 7M°?hi 9 , enera T C ° n,eX ' ,ab ' e ' ° r9aniZed 35 '-gments and stored in 

17zeM7™ " ^ 3 ,ra9men,er P'°9 ram inside °< sv "<ax and semantic an- 

nrJr n a L P ^! erfed embodimenl ° f ,he inven,i °". compiler 660 associates some identifiers to a compiler generated 
program sect on name and an offset relative to the beginning of the named program section. Other modules referenc na 

r^rLf '"I S ° UrCe Pr ° 9ram 202 fe,erenCe ,he S,rUC,UreS usin ° a na ™ °« a -ction ol oblec ccderwhich 
the external structure .s resident, in combination with an offset within the section 

nrrZT 18 T * P " XeSSmS °' a pre,erred embodiment of the present invention. These steps are performed by a 
processor executing a compi.er program Syntax and semantic analyzer 1 710 processes source program 202 to a J re 

ira £ T T* lab ! S ,73 ° imerna ' '° rm 1720 °» ,he source P ro 9' am (Slep -810) Program genera or 
If om ■ ' m ^ aU0n JP ec ' iic Wom»tion into pre-code-genera.,on context table 1 730, using information from a 1° 
of cornp,la.,on l.brary 680 ma, wilt be superseded a, the culmination o, the compilation of source program 202.. 'step 

After code generation, pruner 1755 deletes, or "prunes", certain information from internal context table 1 730 and 
mat^Tr ra, ° r 1750 re ' ra9men,S P—ode-generation context table 1730. The information deleted tv^e " " 
melsl n« T?VJ m T m 2 ° 2 ' WhlCh iS n °' 9 ° in9 *° bS aCC9SSed b * another compilation unit. For exam^n 
d!n^ 3 ?J I e ' W " h 3 C ° mpile " me ini,ial «P~«»i". compiler 660 may generate a fragment for the 
uZ f « 7k rma " " ini,ia ' eXPr6SSi ° n - Sub "*»"«y- P""-' "55 wll delete the initial express 1 
varTaL ,h 3 ? , beCaU ?! T'^ COmpi,a,ion unit needs <° ac cess the initial expression Thus, the fragment for the 

Fragments in pre-code-generation context table 1730 (internal fragments) are compared with fraqments in the 

to f^TL C ° nXe * T3b,e " C0mpMatiOn ' ibrary ■ ^ ™) sSS^c^S 

S.™^ ^ Pr ° 9famS mUSt ^ reCOmpHed 35 the r6SU,t of the compHation of source program^ 

KZmS " C ° mP ' ibrary ^ SUPerSed6d bV wNtin9 the internal context tablG *> ^ ^Pi'ation 
Fig 1 9 shows a processing of step 1 830 of Fig. 1 8 in more detail. In this processing the fragments ol the pre<ode- 
! T tab '. e 1 T S ° rted USin9 3 GREATERT HAN function, which compares variou pans o< pToi 

Spa, of "a ^ h lerarC h hiCa, °H er ^ PUrP ° SeS ° f the GR ^TERTHAN function, it does not matte 

wh.cn part of a fragment is the h.ghest order, provided that a consistent rule is applied. For example the fraqments 

be H he ,H h f ° rder Part ' ,0,, ° Wed by 3ny — P ra ^ m identifier the fragment For 
S a Va ' U t 6 h h ' era ; Chy S ^° U,d be chosen so that Mismatches are generated early, because the comparison is 
optimized when the portions of fragments most likely to be different are compared first. 
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010 Function GREATERTHAN (Fl, F2 : Fragment:) return 
Boolean 
is begin 

020 if Fl. Nature /- F2. Nature then 

030 return Fl. Nature > F2. Nature; 

040 else 

050 case Fl. Nature is 

060 when Subprogram «> 

070 if Fl. Identifier /- F2. Identifier then 

080 return Fl. Identifier > F2. Identifier; 

090 end if; 

100 if PI. Number_of_Parama /» F2 . NumberjsfJParama 

110 return Fl. Nuabe r__o f_P ar ams > F2. Number- 

of_Params; 
T20 end if; 

130 for Each Param loop 

140 if GREATERTHAN (P1,P2) then return True; 

20 end if; 

150 if GREATERTHAN (P2,P1) then return False; 

end if; 

160 end loop; 

170 when Param/Object /Const ant »> 
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180 when Type/ Subtype 

30 

190 end if; end case; 
35 IABLE-1 

Table 1 shows part of a preferred GREATERTHAN function. The GREATERTHAN function compares various fields 
of a pair of fragments in the Global Context Table. The comparison is performed in a descending hierarchical order. In 
this example, the highest order field is the semantic nature of the fragment, which is processed on lines 020-030. If 
40 the semantic natures of the two fragments are different, one of the fragments wilt be greater than the other, as suggested 
on lines 020-030. 

When the natures of the two fragments are both Subprogram, for example, the next field compared is an identifier 
for the Subprogram as shown on lines 070-080. In the code where the identifiers for the Subprogram happen to be the 
same, as is possible in languages that allow overloading, the fragment with the greater number of Subprogram param- 

45 eters is determined to be the greater fragment, as shown on lines 100-110. In the case where the two Subprogram 
fragments have the same number of parameters, the fragments for the parameters themselves are compared using 
recursive calls to the GREATERTHAN function. 

Similar to the case where the natures of both fragments are Subprogram, when the natures of the two (ragmenls 
are both Param, object, or constant, the GREATERTHAN function could contain code to compare the respective iden- 

so tifier, mode, and type in a descending hierarchical order. In general, the GREATERTHAN function can have a separate 
hierarchy of field comparisons depending on the nature of the fragment, although some natures may have a common 
hierarchy of field comparisons. 

Fragments in the pre -code -gene ration context table are sorted using the GREATERTHAN function. (Step 1910) 
The sorting is performed by first sorting all fragments at a first level in the tree of fragments discussed previously in 

55 connection with Fig. 8. Next, the next deepest level of the tree is sorted by separately sorting the fragments within each 
fragment of the first level fragments. Fragments from the corresponding table in the compilation library are sorted in a 
similar manner. After sorting is performed, the fragments in each scope and level of the internal context table are 
matched with corresponding fragments of the corresponding context table from the compilation library. (Step 1920) 



BNSDOCID <EP 08S676BA2_L> 



13 



EP 0 856 788 A2 



10 



IS 



20 



mJl 9 ; 20 S , h ° WS 3 prOCeSsin 9 of step 1920 ° f F >9 19 i" "-ore detail. II should be understood that in some embodi- 

^ poin e'r T^tTnZ ^T^'T " *"> ™ ^ R * 20 ' a " -.em al\ag™n. 

ist po.n ter s set to the head of the l.st of sorted internal fragments (internal fragments) (step 2010) and a Hbrarv 

sSZtZ K Se ,' T* '* 01 ,ra9memS " ' he corresp °" d -9 library contex. ta'b.e (,ibra»en1s^ 
^ he inZr f 6 a ^ , 6 ^ " a9ment ,iS ' * GREATERTHAN current entry in the infernal library .is 
" T? 9 Tn ' PO ' mer ' S mwd 10 ,he neXt en "y in ,he intemal <™9mert lis. (step 2040?and 
o^n^TTT " 30 " CUrfen ' " n °' GREA ™™AN the internal (ragmen, step 2030 ° is 

fntmT Cmen ^45^^ " a9men ^ GREATERTHAN the — .ragmen, (2050). If the current 

Ln,™ r n h?,r , GREATERTHAN the "brary fragment, the library fragment list pointer is moved to the next 

n.hZ 11 ?I 9 51 COn,r °' Pr0CeedS 10 S,ep 2030 " neilhe ' curre "< lament is GREATERTHAN the 
other, .he current fragments are considered to be a match (step 2070). Next, the internal fragment lis. po nte^r is moved 

S^HhTE (S 'T I"* " " de,9rmined Wh6,her " a9men,S f6main in the i"terna^ragmen. P ,is, s e P ^85) 

fe^afn In ,hV,^ ^ P °' n,er te moved «° ,he ™« °<«<V <«• P 2090) and i, is determined whether entries 

Zml .1, f a9me :' " S ' (St6P 2 ° 95) " an en '^ remainS in Mh tne inte ' na ' 'nigmani lis. and the lib™ 
fragment list, control proceeds to step 2030. uuiaiy 

snrt^'nh^f Pre,err f embodlrnenl °' the presenl invention processes both a sorted internal fragment list and a 

a foment 1 h,?™ T h ! ' nV r ,i0n ^ be PraC,,Ce<j by S ° nin9 0nl V ° ne °« IheSB tw ° «««■ S oq U en,ia„y selling 
a fragment in the unsorted list, and performing a bhary search of the selected fragment in the sorted list 

franm-i a Processing of s.ep 2070 ol Fig. 20 in more detail Invocation specific information of the matching 

tab? Ten uZ COrnPared H ' 0 d ? ,ermine " ,he ,ra 9 men,s ™ Wlenl. (Step 2110) In step 2,30. certain global context 
speciffc C ° nS ,0 ^ inV0Ca ' i0n SpedfiC - F ° r 6Xample ' 0f,5ets wilhin a P ro 9ram section are invocatTon 

If the two fragments are found to be equivalent (step 2120) the version identifier of the library fragment is stored 
« IsteP 21407 21 ° ,herW ' Se ' 3 neW ' y 9enera,ed VerSi ° n iden,i,ier iS St ° red M °* e -'-nalfragmem 

ConlexT^ 6r,oT,!r m n,T eP '^f ^ ^ 65 P ' 09ram 9Snera '° r 1750 reads *° m Global 

606 ^™ h, ,L P J° 9enera,e 3 " eW COn ' eX ' table 1730 1,131 is ^"ivalent with the Global Context Table 
Tal 60^ ma t h SenSe , ' T' ^ P '° 9 ' amS *" ° n P'-°™P« a 'i°n contents o, Global Contex, 

^ ,™ ! L Pos.comp,lat,on contents of Global Context Table 606 without recompiling Object-program 

Pre code oenlT , 65 *" P'™^™*™ '° '-gments from ihe compilation libra^ 

v e J™ tT r 9 processed wi,h the ' ibrarv fragments using a me^od similar to the method the 

,p„ w 1 r pr °= eSS,n9 emplovs to process Post-code-generation fragments with the library fragmente^e 
s no, oeZm^h 6 bs ^Z^^^on fragments and the library fragments and thelra^ fragments 
L7L«TZ ? T 6r ' S ° rtin9 S,SP maV USS ,6Wer fields ,han in ,he ve rsion Henraer proving. 

66^ Simi^lv , h ° aCCOmm0da ' e chanQes lha ' are m ade ,o a fragmen, during the code generation phase of compiler 
660.S,mHarly.,he,ragmen,ma,chupma y bemorelenient*anthematchupperformedfor.heversion^ 

sorti^onT^hn,''* pre - c ° de -9 enera,ion ' ra 9r"ents are matched with ,he library fragments using the double 
tunc Z ^a^M Qre^ H "S?- * T^" 9 diSCUSS9d preVi ° U ^ h applica,ion A ^ified greater than 
men s^ m GR-EAtIrthaJ ^ ," ^ **" '° S ° rt * h ° pre - code -9^^a.ion fragments, and to son library frag- 

^ul in In ? .kIk C "° n ma/ C ° mpare t8Wer fields ,han tne GREATERTHAN function described pre- 

viously in connection with the version identifier processing 

taN *' SO *" 9 " si "9 ,he M-GREATERTHAN function, the fragments in each scope and level of the internal context 
contexTtable in ?h US ' n9 T, M - GREATERTHAN corresponding libra'ry Iragments o, the coTespond"g 

G^T E S^ , rT n ^ 9 22 Sh ° WS 9 PrOCeSSin9 °' S,SP 1820 °' Fi9 18 ' includin 9 matching using 
h , «T H ^11 ll0n ' m0re de ' ail The processin 9 o« "9 22 is similar tothe processingof Fig 20 except 

read a^TnTf f h ' UnC,i0n " USed inS * ead °* ,he GREATERTHAN function, and tha, step ^^olnVTg 22 

Irflr, 5 Tvn lh ' mat * ln 0 ,nlemal "tV™* inslead ol a «i9ning a version identifier to the matching internal fragment 

albcationir oe ^mJ, TiTf °' ' eSen ' n9 ' 3 r6S ° UrCe " eeded by ,he * ra9ment ln 9 enera " a,,er 

allocation ,s performed for matching fragments, allocation -is performed for the non-matching fragments 

If the matches I fragment is a variable or a procedure declaration, step 2270 may operate to preserve an intra- 
a eas o'n 'l^T, case ' s,ep 2270 may empioy genera, purpose procedures for preserving memory 

J r'" 9 m6m0ry allOCa,i ° n techr "W° s - such as tiling- or bit maps, an procedures to allow for 

the reservation of memory starting at certain offsets. For example, in addition to a procedure for reserving an area of 

c n HsTt 0 i7possib^ a ' n SiZ6 ' 3 PrOCedUre a ' S ° eX ' S,S PfeSerVin9 a " areamem °ry °' a «rtain «• ^ a ting at a certain 

fr^nmfn 3 i ndiCa ," n9 ,esou,ce ' such as a ofl.«. may be stored dueclly in the pre-code-generation 

fragment or instead may be stored in a table 
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In the case where the matching fragment is a variable. Figs. 23(a) and 23(b) show a result of processing of a 
preferred embodiment of the present invention. In Fig. 23(a), a program includes an indentifier called "date". A first 
compilation generates invocation specific information including an intra-program-section offset of 0 for "date" in context 
table 606", which is a simple abstraction of the context table discussed in connection with Fig. 15. Fig. 23(b) shows 

5 the result of a second compilation of package P after a variable "time" has been added to the package. The second 
compilation preserves the intra-program-section offset of 0 for "date". Thus, other programs that were previously com- 
piled and linked with the results of the first compilation of package P need not be recompiled. 

In contrast, Fig. 24(a) and 24(b) show a result of processing without the benefits of this preferred embodiment of 
the present invention. A first compilation generates invocation specific information including an intra-program-section 

JO offset of 0 for "date", as described in connection with Fig. 23(a). Fig. 24(b) shows the result of a second compilation 
after package p has been edited to add a variable "time". The results of the second compilation includes an intra- 
program-section offset of 8 for "date", which is different from a program section offset in the first compilation result. 
Consequently, other modules that reference "date" must be recompiled to reference the correct offset within the program 
section containing a memory area for the variable "date". 

is in a preferred embodiment of the present invention, there are two types of invocation specific information for pro- 

cedure declarations: an intra-section offset and a program section name. When processing causes the compiler to put 
multiple globally defined procedures within one program section name, an attempt is made to preserve intra-section 
procedure offsets to produce a result similar to the result described in connection with Fig. 23. 

Fig. 25 shows an overview of program section name processing of a preferred embodiment of the prevent invention. 

20 First, it is determined whether a program section pre-code-generation fragment tentatively matches a library fragment. 
Step 2510 corresponds to the tentative matching processing discussed above. If there is no tentative match, a name 
is generated for the program section based in part on sequentially generated data. (Step 2520) It is determined whether 
the generated name is already used by determining if the name is on a reserved list of names. (Step 2530) If the name 
is on the already reserved list of names processing passes to step 2520. Otherwise, the generated name is assigned 

25 to the program section (stop 2540) and tho name is then added to the reserved list of names. (Step 2550) If the program 
section prefragment does correspond to the a library fragment, it is determined whether the program section name of 
the library fragment is on the reserved list of names. (Step 2560) The processing of step 2560 may be necessary in 
the event that the compiler assigns sequentially generated names in processing other than the processing shown in 
Fig. 25. If the library name is not on the reserved list of names, the library name is assigned to the prefragment (step 

30 2570) and the library name is added to the reserved list of names (step 2550). 

In a preferred embodiment, the steps shown in Fig. 25 are not necessarily executed in temporal proximity to each 
other. Instead, the steps shown in Fig. 25 may be interleaved with other processing of a preferred embodiment. 

Because the N/L GREATERTHAN function does not comparing as many fields as the GREATERTHAN function 
described above, the match using M_GREATERTHAN tends to be more lenient than the match using GREATERTHAN. 

35 Because of the lenient matching, there is a possibility that a pre-code-generation fragment might be matched with a 
noncorresponding library fragment. Any mismatching should not result in incorrect processing, since a mismatch should 
merely cause an allocation that will make the new fragment not equivalent to the old fragment in the version identifier 
processing discussed above. 

In some implementations, the lenient matching may cause multiple pre-code-generation fragments to match to a 

40 common library fragment. If such a common match occurs, processing should ensure that multiple pre-code -generation 
fragments are not assigned the same resource as a result -of reading a common hint from the common library fragment. 

The M_ GREATERTHAN function is used to compare the pre-code-generation fragments to the compilation library 
fragments, because code generator 1750 and pruner 1755 may affect the internal context table. M_GREATERTHAN 
does not compare certain parts of a pre-code-generation internal fragment, that are subject to change by code generator 

45 1 750 or pruner 1 755, with a corresponding part of a library fragment. 

Fragmenting the Global Context Table operates to segment a program into a plurality of parts. As the fragmenter 
generates a tree structure, the fragmenter operates to generate a graph of parts, including a part identifying a plurality 
of other parts. 

Although in a preferred embodiment the memory structure in which replacement of a compilation result occurs is 
so a compilation library, the memory structure in which replacement occurs need not limited to a compilation library. For 
example, replacement may occur in a memory structure defined by list of file specifications, such as a list of object file 
specifications processed by a linker to generate an executable image. In a system supporting multiple versions of files, 
the absence of a file name version number in a file name specification typically means the highest version of the named 
file. In such a system, compiling a source file to produce a new object module having a version number greater than 
ss a corresponding previous object module constitutes a replacement in the memory structure defined by the file speci- 
fication list passed to the linker, since the generation of the new object module results in the previous object module 
not having the highest object file name version number. 

Similarly, the memory structure in which replacement occurs may be a memory siructure defined by the INCLUDE 
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statements in a particular source file. 

Hin's Preferably can pertain to ihe size- of an area to allocate fo, a variable. In some cases the hint for the size 

For example, occasionally there are conditions that force data to be a particular size For example if a data item is 

bTToES TZ an ? ^ TTL™ Wi " en " 3 differen ' lan9Ua9e ° lhe ' ,ha " Ada comp I mTg 

oe forced to use a particular size for the data item. 

oiH J^!o P T T P6rtain l ° mS Si2e ° f 3 m0dU,S For example * if a new versi ° n °f a module is smaller than the 

Hints may pertain to the registers used to pass parameters to procedures or functions 

could D^^'Tfh^^^ t6ndS t0 ad ° Pt himS eaMy ^ the C ° de 9eneration P rocess ' an a,ternat ™ ^PProach 
hTntl , ! ^ 9e !: erat,0n nClUdin9 thG 9eneration of 8 G,obal Context Ta bfe without reference to 

hint* and subsequently shuffle or adjust values of the invocation specific information in the completed Global Context 

Un^rZZ ofthe compiler program ,s not necessary for practice of the invention, because selective invocation of the 
linker may operate to selectrvely translate a program in response to whether there is a substantial difference between 
17£TIZT H lthOU9h 3 Pref8rred emDOdiment inC ' UdeS 3 ,inker P ~ lhat is ^istinc^from" 

» Sht 1 rr b d :^r require that there be any such partiuon ° f fu - tos ior *• « ■ p~ 0 

In a preferred embodiment, translating a program into a machine executable program involves processina the 

Tan be llrm n k Pr ° 9 ^ m f 8 96nerated *° r the com P i,ation ° f the various source files The translation 
can be performed, however, with solely a linker or solely a compiler. 

nrJL addlti ° n l ° Smart recom P i,ation - hint readin 9 c °"'d also be' used, for example, with VMS shared images to 

cou" be reZirT,^" 5 " 5 thr ° U9h SUbSeqUGnt re!eaSSS ° f 3 Further " in FORTRAN and C( JfhLs 

could be used to attempt to cause the layout of common blocks, structures, etc. to be the same across multiple object 

bv chanaeT int™ T "f" 9 * 3 ernbodiment mav also be "«* '° minimize relinking caused 

by changes .n transfer vectors among shared images, or to minimize relinking caused by changes in debugging infor- 
mation among respective modules of the system. ueouggmg inior 

In a chip design/layout, or other CAD/CAM system, hint reading can be applied to minimize rebuildina when a 

"nouarl sV eViS f - USSr ' nPUt t0 3 ° AD/CAM SVStem ^ 56 tOP ° l09ical ^ Worma,^ 
certain H,t a " ° ™™ commands - or other convenient form. The user input corresponds to a program and 

r^sla'on rLT * CAMAM ' W 35 3 8pecWc ChiP l0Cato or 9— ^ corresponds"' 

varialionrcantp 11^,^?" ^ eXamP ' eS be Considered as apiary only; various modifications and 
variations can be made to the present invention without departing from the scope or spirit of the invention. 
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Claims 
1. 



ltepsT PUter SySt9m inC ' Udin9 3 mem0ry ' 3 meth0d 01 COmpilin9 S ° UrCe P r °9 rams - the method comprising the 



2. 



compiling a first program to produce a first compiled program and a first set of postcode generation information 
characterising the first compiled program; 

compiling a second program lo produce a second compiled program using the first set of postcode generation 
information to minimise differences between the first and second compiled program 
determining differences between the first and second compiled programs- and 

comp.hng a third program dependent upon the differences between the first and second compiled programs. 
The method of claim 1 , wherein the step of compiling the first program includes 
segmenting the first compiled program into a plurality of first parts- and 

wherein the first set of post-code generation information which characterises the first compiled program in- 
cludes post-code generation information which characterises the plurality of first parts 
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3. The method of claim 1, wherein said first set of post-code generation information includes a hint corresponding to 
an offset from a beginning of a data area in the first compiled program. 

4. The method of claim 1, wherein said first set of post-code generation information includes a hint corresponding to 
s a size of a data area in the first compiled program. 



5. The method of claim 2, wherein said first set of post-code generation information includes a hint identifying one 
of the plurality of first parts. 

10 6. The method of claim 1 , wherein the step of compiling the second program includes 



segmenting the second compiled program into a plurality of second parts; 

producing post-code generation information characterising the plurality of second parts using the first set of 
post-code generation information; and 
is wherein the determining step further includes comparing corresponding parts from the first and second plurality 

of parts to determine differences between the first and second compiled programs. 



7. The method of claim l , wherein 

20 the first and second compiled programs each include program sections, each program section having a section 

name and a portion of allocated memory and wherein said post code generation information includes a hint 
pertaining to a physical memory reference represented by a section address comprising a section name, and 
an offset. 



25 8. The method of claim 1 , wherein said post-code generation information includes a hint pertaining to a register and 
a corresponding register offset used as an address for a compiler temporary variable. 

9. The method of claim 1, wherein said post-code generation information includes a hint pertaining to data and code 
alignment requirements 

30 

10. The method of claim 1 , wherein said post -code generation information includes a hint pertaining to registers used 
in passing parameters in an outbound procedure call. 

11. " The method of claim 1, wherein said post-code generation information includes a hint pertaining to size allocation 
35 of a variable. 



12. The method of claim 1, wherein said post-code generation information includes a hint pertaining to code and data 
allocation of a module. 

40 13. The method of claim 1 , wherein said post -code generation information includes a hint pertaining a register and a 
corresponding register offset representing the address of a routine in the first and second compiled programs, 
respectively. 
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FIG. 5 

£-502 

CREATE 
FRAGMENTS FOR 
ALL SOURCE 
PROGRAMS 



^- 504 

DETERMINE 
WHICH SOURCE 
PROGRAMS NEED 
TO BE 
RECOMPILED 



t ,— 506 

GENERATE 
OBJECT CODE 
FOR SOURCE 
PROGRAMS 
THAT NEED TO 
BE RECOMPILED 
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FIG. 7 



222 



CREATE FIRST GLOBAL 
CONTEXT TABLE: GENERATE 
FIRST OBJECT CODE; STORE 
BOTH (N COMP. UB. 
(INCLUOES INVOCATION 
SPECIFIC INFORMATION) 



702 



RECOMPILE SECOND SOURCE JUODUlT^ 04 



JL 



705 



LOAD FIRST FRAGMENTED GLOBAL CONTEXT 
TA8LE FROM COMPILATION LIB. 



i 



JL 



706 



S^JF SECOND GLOBAL CONTEXT TABLE 
AND FRAGMENT IT (INCLUDES INVOCATION 
SPECIFIC INFO.) 



JZ1 



ASSIGN NEW 
VERSION ID 
TO FRAGMENT 




1 



(STEPS 704 THROUGH 
71 6 ARE PERFORMED 
FOR EACH SOURCE 
PROGRAM MOD. TO 
BE RECOMPILED) 



FRAGMENT OF 2D GLOBAL 
CONTEXT TABLE DIFFERENT 
FROM ALL FRAGMENTS 
IN 1ST GOT? 



N 



ASSIGN SAME VERSION ID AS 
MATCHING FRAGMENT OF 
1STGCT 




3 



714 



STORE FRAGMENT OF 2D GCT 

AND ITS VERSION ID IN 
COMPILATION UB. 




RECOMPILE ALL SOURCE 
MODULES THAT DEPEND ON 
CHANGED FRAGMENTS (TO STEP 704) 



4 
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FIG. 8(a) 

£-800 

package PKQ is ] 

I : Integer J 

type R is I 

record j 
C1 : Integer; 

C2: Float; i 

end record; j 

package Inner is , 

I : Integer; i 

end; { 
end; j 
j 



FIG. 8(b) . 

jrJio 



package PKG is 



: Integer 




814 V/ 



package Inner is 



C1 : Integer 



C2 : Float 



\ 



: Integer 



v. 



This tree can be broken into fragments, as is shown by 
the dotted outlines [and numbered]. 
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606 



GLOBAL SYMBOL TABLE 



GLOBAL SYMBOL NAME 



PROGRAM SECTION NAME 



PROGRAM: SECTION OFFSET 



FOR ONE 
>- GLOBAL 
IDENTIFIER 



604 



PROGRAM SECTION CONTRIBUTION TABLES 



PROGRAM SECTION NAME SP1 1 



PROGRAM SECTION CONTENTS 



PROGRAM SECTION NAME SP1 



PROGRAM SECTION CONTENTS 



ONE 
> PROGRAM 
SECTION 
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1018 



1002 



80' 
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FIG. 10 



DECLARATIONS 



•.Nature (Subprogram, Param, Object/ 

Constant Type, Subtype, etc) 
JdenMer_(exj_Aflc™GEI^ 

i.Number_of_Params (ex3) 



global symbol name 
offset (optional) 
Jizejocirepresentation 



(if not defined by the language) 
offset within stack frame 



0856766A2_L> 



27 



EP 0 856 788 A2 



FIG. 11 



CREATE GLOBAL CONTEXT 
TABLE ROUTINE 



1100 



1102 



CREATE FIRST GLOBAL CONTEXT 
TABLE, GENERATE FIRST OBJECT 
C ?DE, STORE BOTH IN COMPILATION 
LIBRARY (INCLUDES INVOCATION 
SPECIFIC INFORMATION) 



I 



1104 



DIVIDE GLOBAL 
CONTEXT TABLE 

INTO A FIRST 
GROUP OF 

FRAGMENTS 



1106 



STORE OBJECT 
CODE AND FRAG- 
MENTED GLOBAL 
CONTEXT TABLE 
IN COMPILATION 
LIBRARY 
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FIG. 12 



STORE SEMANTIC INFORMATION SUBROUTINE 

12QQ 



1202 



STORE 
NATURE ID 




1204 



1208 



1212 



STORE 
OTHER ID'S 



1216 



STORE NUMBER 
OF PARAMETERS 



1218 



STORE TYPE 
OF PARAMETERS 



CONTINUE 
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FIG. 13 



STORE INVOCATION SPECIFIC 
INFORMATION SUBROUTINE 

1300 



1302 



DOES 

DECLARATION CONTAIN* 
GLOBAL SYMBOL 
NAME? 



r 



1304 



STORE GLOBAL 
SYMBOL NAME 



1306 



DOES 

DECLARATION CONTAIN" 
jSEE INFORMATION FOR 
.A VARIABLE ? 



r 



1308 



STORE SIZE 



N| 



_ 1310 

DOES ' _ 
DECLARATION CONTAIN REPRE^ 
^ENTATON INFORMATION ! 
A VARIABLE? 



1312 



STORE REPRE- 
SENTATION 



1314 



DOES _ 
DECLARATION CONTAIN" 
OFFSET INFORMATION 
.FOR A STACK 



1316 



STORE OFFSET 
INFORMATION 
FOR STACK 



CONTINUE 
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FIG. 14(a) 

procedure example is 
V : Integer; 

C : constant Integer : » 12; 
1402 j procedure P(X : Integer); 
^ procedure P(X : Float); 

procedure DependentJJnit is separate; 
procedure P(X : Integer) is begi n V : » V+C+X; end; 
procedure P(X : Float) is begin V : » V+C+lnteger(x); end; 

begin 

DependentJJnit; 
end; " 

1404 ! ~ J 

separate (Example) 

procedure DependentJJnit is 
begin 

P(1.0); 

endj^ ^ j 



FIG. 14(b) 



r m 

1410 | Package Pis 

type T is array (detbounds) of Integer 
i where detbounds is a global function 
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1602 -w compilation unit Example at line 1 

I 0.. 0»>E311E2C3 0095C46C 
1 602 procedure body Example at line 1 

I 1.. 1=>E311E2C3 0095C46C 
1 602 -w. body : . 

I 4.. 4«>E311E2C3 0095C46C 

1502-w ...decls : 

I 5.. 5»>E311E2C3 0095C46C 

— variable Vat line 2 

6 . . 6 u >E31 1E2C3 0095C46C 

. . . . constant G at line 3 > - 

7.. 7.>E311E2C3 0095C46C 




1610 



FIG. 16 J 



, procedure specification p at fine 4 
8.. 10->E311E2C3 0095C46C 

. procedure specification P at the 5 
11 .. 13->E311E2C3 0095C46C 

■ procedure body Dependent_Unit at line 6 

14.. 14->E311E2C3 0095C46C 
. . stub 

15 . . 15 . >1311E2C3 0095C46C 
. procedure body P at line 7 

16 . .16 - >E311E2C3 0095C46C 
. . decls 

17 . . 17 « >E311E2C3 0095C46C 
. . . subprogram 'in' formal x at line 7 

18 . . 18 . >E311E2C3 0095C46C 

■ procedure body P at line 8 

19 . .19«>E311E2C3 0095C46C 
■ . decls 

20 . .20 « >E311E2C3 009SC46C 



-16066 
■16067 



subprogram 'in' formal x at line 8 
21 . .21 »>E311E2C3 0095C46C 
. decls 

2 . . 22 - >E311E2C3 0095C46C 

16 <32 ij . . constant SCODE at line 0 

I 23 . . 23 - >E31 1 E2C3 0095C46C 



16021 



•1606 
■1604 
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FIG. 18 

1800^ 

| ^- 1810 

PERFORM SYNTAX AND 
SEMANTIC ANALYSIS 



I 



z: 



1820 



STORE INVOCATION SPECIFIC 
INFORMATION INTO INTERNAL 
CONTEXT TABLE 



I 



1825 



PRUNE INTERNAL 
CONTEXT TABLE 



I 



1830 



COMPARE INTERNAL 
FRAGMENTS WITH 
LIBRARY FRAGMENTS 



I 



1840 



STORE INTERNAL 
CONTEXT TABLE INTO 
COMPILATION LIBRARY 



T 
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1900 



FIG. 19 



1910 



SORT INTERNAL FRAGMENTS, 
USING GREATERTHAN FUNCTION; 

SORT LIBRARY FRAGMENTS 
USING GREATERTHAN FUNCTION 



1920 



MATCH INTERNAL FRAGMENTS 
WTTH LIBRARY FRAGMENTS, 
USING GREATERTHAN 
FUNCTION 



T 



21000 , 



■2110 



■2120 





N 

Fy 


i 


/-2140 


ASSIGN LIBRARY VERSION 
ID TO INTERNAL FRAGMENT 




ASSIGN GENERATED VERSION 
ID TO INTERNAL FRAGMENT 














r 
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FIG. 20 



20000 



r 



2010 



START AT HEAD OF INTERNAL UST 



2020 



START AT HEAD OF LIBRARY UST 



MOVE TO NEXT 
INTERNAL FRAG- 
MENT 




MOVE TO NEXT 
LIBRARY FRAG* 
MENT 




ASSIGN VERSION ID 
TO INTERNAL FRAGMENT j 



2049 



2080 



MOVE TO NEXT 
INTERNAL FRAGMENT 



2085 




/-2090 



MOVE TO NEXT LIBRARY 
FRAGMENT 
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FIG. 22 



22000 



2210 



START AT HEAD OF INTERNAL LIST 



2220 



START AT HEAD OF LIBRARY LIST 




MOVE TO NEXT 
INTERNAL FRAG- 
MENT 



MOVE TO NEXT LIBRARY 
FRAGMENT 
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FIG. 25 




ASSIGN GENERATED NAME 
TO PROGRAM SECTION 



c 



2540 



^-2570 



ASSIGN NAME OF 
PREVIOUS STRUCTURE 
TO PROGRAM SECTION 



ADD NAME TO 
RESERVED UST 



c 
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